为了加快页面渲染，我们常使用先缓存后网络（StaleWhileRevalidate）策略将本地缓存作为响应快速返回给用户，同时从网络中获取最新资源并更新缓存，最后通知页面进行更新。由于 Service Worker 与页面运行在不同的线程环境中，故需要一种机制来保证缓存更新后页面能够及时得到通知。在 Workbox 中，我们可以使用 workbox-broadcast-cache-update 模块来实现这一需求，接下来就让我们一起来探究该模块的使用

# 基本使用

workbox.routing.registerRoute(
  '/articles',
  new workbox.strategies.StaleWhileRevalidate({
    plugins: [
      new workbox.broadcastUpdate.Plugin({
        channelName: 'workbox',
        deferNoticationTimeout: 1000,
        headersToCheck: ['Content-Length', 'ETag', 'Last-Modified']
      })
    ]
  })
);

@前端进阶之旅: 代码已经复制到剪贴板

上例中，当请求 /articles 的缓存更新后，只要新响应头信息中 Content-Length、ETag 或 Last-Modified 的值有任何一个与旧响应头信息中相关属性的值不一致，便会向频道 workbox 广播缓存更新消息。其中 workbox.broadcastUpdate.Plugin 构造函数的参数为含有以下属性的对象：

channelName：频道名称（默认值为 workbox）。
headersToCheck：出于效率的考量，Workbox 通过比对前后两个响应的头信息来判断响应是否更新，我们可通过该属性来设置需比对的头信息（默认值为 content-length、etag和 last-modified）。
deferNoticationTimeout：当请求为导航请求，且相关缓存有所更新时，Workbox 会延迟广播直到页面准备妥当（页面可通过调用 navigator.serviceWorker.controller.postMessage 发送 {type: 'WINDOW_READY', meta: 'workbox-window'} 消息来告知 Workbox），同时也为了避免无限制地等待，我们可通过该属性以要求 Workbox 在等待指定时间后，无论是否收到页面通知，都将立即广播更新消息（默认值为 1000，单位为毫秒）

由于 workbox.broadcastUpdate.Plugin 内部使用了 workbox.broadcastUpdate.BroadcastCacheUpdate 来处理缓存更新广播，因此在自定义的请求策略中，可直接使用它来处理缓存更新广播，比如：

const broadcastUpdate = new workbox.broadcastUpdate.BroadcastCacheUpdate({
  channelName: 'workbox',
  deferNoticationTimeout: 1000,
  headersToCheck: ['Content-Length', 'ETag', 'Last-Modified']
});

const cacheName = 'cacheName';
const url = 'http:/127.0.0.1:8080/articles';
const cache = await caches.open(cacheName);
const oldResponse = await cache.match(url);
const newResponse = await fetch(url);

broadcastUpdate.notifyIfUpdated({
  oldResponse,
  newResponse,
  url,
  cacheName
});

@前端进阶之旅: 代码已经复制到剪贴板

上例中，我们通过调用 workbox.broadcastUpdate.BroadcastCacheUpdate 实例的 notifyIfUpdated 方法，以便在缓存更新后广播相关信息。该方法的参数为含有以下属性的对象：

oldResponse：已经缓存的请求响应。
newResponse：新的将要被缓存的请求响应。
url：请求的 URL（字符串，非 URL 类型）。
cacheName：缓存名称。
event：触发请求的 FetchEvent 对象，该属性为可选属性。

上文对 Service Worker 中的处理进行了介绍，此处需要牢记：无论是使用 workbox.broadcastUpdate.Plugin 还是 workbox.broadcastUpdate.BroadcastCacheUpdate，由于它们都是根据响应头的差异来判断缓存是否需要更新，因此如果我们将它们作用在不透明响应上，更新广播将永远不会触发。

完成了 Service Worker 中的设置，接下来就需要在页面中监听此消息，相关代码如下：

if ('BroadcastChannel' in window) {
  const workboxChannel = new BroadcastChannel('workbox');
  workboxChannel.addEventListener('message',  event => {
    console.log('Receive message from ServiceWorker:', event.data);
  });
} else {
  navigator.serviceWorker.addEventListener('message', event => {
    console.log('Receive message from ServiceWorker:', event.data);
  });
}

@前端进阶之旅: 代码已经复制到剪贴板

上例中，如果浏览器支持 BroadcastChannel API，则监听 BroadcastChannel 的 message 事件，否则监听 navigator.serviceWorker 的 message 事件，回调参数 event.data 为含有以下属性的对象：

type：消息类型，值为常量 CACHE_UPDATED。
meta：元属性，值为常量 workbox-broadcast-cache-update。
payload：缓存相关信息，值为含有以下属性的对象：
cacheName：缓存名称。
updatedUrl：已更新的缓存地址（字符串，非 URL 类型）

# 消息总线

上文提到了 BroadcastChannel，通过它我们可以实现 Service Worker 与页面的相互通信，当然也可使用 postMessage 或 MessageChannel 来实现此功能。究竟这三种技术有何区别？它们各自的适用场景又该如何？本节将为一一为大家进行介绍。

# postMessage

通过 postMessage 可实现不同窗口（比如：iframe、WebWorker 或 ServiceWorker）间的相互通信。同时，由于该方法允许来自不同源的脚本进行有效且安全地通信，它也常作为跨域通信的有效解决方案。此方法的使用如下：

otherWindow.postMessage(message, targetOrigin, transferList);

@前端进阶之旅: 代码已经复制到剪贴板

otherWindow：其他窗口的一个引用，比如 iframe 的 contentWindow 属性、执行 window.open 所返回的窗口对象、已命名或数值索引的 window.frames、Worker 或 ServiceWorker实例。
message：需要发送给 otherWindow 的数据，其值为可被结构化克隆算法序列化的所有类型。
targetOrigin：通过该参数可控制消息能够发送给哪些窗口；只有目标窗口的协议、Host 地址及端口号与该参数的值完全相同，此窗口才能接收信息；当值为 * 时，则表明任何窗口都可以接收信息。
transferList：可选参数，Transferable 对象数组，这些对象的所有权将转移给消息的接收方，并且在所有权转移之后，消息的发送方将不能再操作该对象，否则将抛出异常。

于 Worker 或 ServiceWorker 与注册它的页面遵循同源策略，因此它们的实例方法 postMessage 的参数与上述有所差异，依次为 message 和 transferList，类型则与上述相关参数相同。

目标窗口可通过监听 message 事件来接收消息：

addEventListener('message', event => {
  // doSomething...
});

@前端进阶之旅: 代码已经复制到剪贴板

回调参数 event 为 MessageEvent 对象，主要包含以下属性：

data：从其他窗口发送的消息对象。
origin：消息发送窗口的源。
source：消息发送窗口的引用。

# MessageChannel

除了 postMessage，我们也可以使用 MessageChannel 来实现不同窗口间的相互通信，它与 postMessage 的主要差异有：

MessageChannel 的通信双方必须遵循同源策略，不能进行跨域通信。
MessageChannel 无需维护通信双方实体的引用。
MessageChannel 的使用如下所示：

// index.html
const messageChannel = new MessageChannel();
messageChannel.port1.onmessage = event => {
  // doSomething...
};
navigator.serviceWorker.controller.postMessage(
  'Message from UI thread',
  [messageChannel.port2]
);

//sw.js
self.addEventListener('message', event => {
  // doSomething...
  event.ports[0].postMessage('Message back from Service Worker');
});

@前端进阶之旅: 代码已经复制到剪贴板

上例中，我们在页面中创建了信道实例 messageChannel，然后通过信道的两个端口 messageChannel.port1 和 messageChannel.port2 完成不同窗口的通信。端口的使用规则如下：

创建信道的窗口（此处为 index.html）使用端口 port1，并设置此端口的 onmessage 属性来接收另一端口发送的消息;
调用 postMessage（此处为 navigator.serviceWorker.controller.postMessage）方法将端口 port2 作为参数 transferList 的值，以消息的形式发送给另一个窗口（此处为 sw.js）；
在 sw.js 中监听 message 事件，并通过 event.ports[0] 来获得从 index.html 传递过来的信道端口，然后便可调用端口的 postMessage 方法来发送消息给 index.html。

其中：

event 参数为 MessageEvent 对象，主要属性上文已进行说明，此处不再重述。
postMessage 方法的参数依次为 message 和 transferList，具体类型上文已进行说明，此处不再重述。

# BroadcastChannel

其中：

# 基本使用

# 消息总线

# postMessage

# MessageChannel

# BroadcastChannel

# 总结

Workbox 详解篇 8 缓存更新广播|PWA专题

Workbox 详解篇 8 缓存更新广播|PWA专题